home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / info-service / www / doc / http-spec.txt < prev    next >
Text File  |  1993-07-16  |  44KB  |  1,219 lines
  1.  
  2.  
  3. Hypertext Markup Language (HTML)          Tim Berners-Lee, CERN
  4. Internet Draft                      
  5. Expires 14 January 1994                            14 July 1993
  6.  
  7.  
  8.                   Hypertext Transfer Protocol (HTTP)
  9.                 
  10.       A Stateless Search, Retrieve and Manipulation Protocol
  11.  
  12.  
  13.  
  14. Status of this memo
  15.  
  16.    This document is an Internet Draft. Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its Areas,
  18.    and its Working Groups.  Note that other groups may also distribute
  19.    working documents as Internet Drafts.
  20.    
  21.    Internet Drafts are working documents valid for a maximum of six
  22.    months. Internet Drafts may be updated, replaced, or  obsoleted by
  23.    other documents at any time.  It is not appropriate to use Internet
  24.    Drafts as reference material or to cite them other than as a
  25.    "working draft" or "work in progress".
  26.    
  27.    This document is a DRAFT specification of a protocol in use on the
  28.    internet and to be proposed as an Internet standard.   Discussion
  29.    of this protocol takes place on the www-talk@info.cern.ch mailing
  30.    list -- to subscribe mail to www-talk-request@info.cern.ch.
  31.    Distribution of this memo is unlimited. 
  32.    
  33. Abstract
  34.  
  35.    HTTP is a protocol with the lightness and speed necessary for a
  36.    distributed collaborative hypermedia information system.  It is a
  37.    generic stateless object-oriented protocol, which may be used for
  38.    many similar tasks such as name servers, and distributed
  39.    object-oriented systems, by extending the commands, or "methods",
  40.    used.  A feature if HTTP is the negotiation of data representation,
  41.    allowing systems to be built independently of  the development of
  42.    new advanced representations. 
  43.    
  44. Note: This specification
  45.  
  46.    This HTTP protocol is an upgrade on the original protocol as
  47.    implemented in the earliest WWW releases.  It is back-compatible
  48.    with that more limited protocol.
  49.    
  50.    This specification includes the following parts: 
  51.    
  52.       The Request 
  53.       
  54.  
  55.  
  56.  
  57. T. Berners-Lee                                                       1
  58.  
  59. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  60.  
  61.       Methods 
  62.       
  63.       A list of headers in the request message 
  64.       
  65.       Status codes 
  66.       
  67.       A list of headers on any object transmitted 
  68.       
  69.       Format negotiation algorithm 
  70.       
  71.       The HTTP Registration Authority 
  72.       
  73.       References 
  74.       
  75.    The following notes form recommended practice not part of the
  76.    specification:
  77.    
  78.    Servers tolerating clients
  79.    
  80.    Clients tolerating servers 
  81.    
  82. Purpose
  83.  
  84.    When many sources of networked information are available to a
  85.    reader, and when a discipline of reference between different
  86.    sources exists,  it is possible to rapidly follow references
  87.    between units of information which are provided at different remote
  88.    locations.   As response times should ideally be of the order of
  89.    100ms in, for example, a hypertext jump, this requires a fast,
  90.    stateless, information retrieval protocol.
  91.    
  92.    Practical information systems require more functionality than
  93.    simple retrieval, including search, front-end update and
  94.    annotation. This protocol allows an open-ended set of methods to be
  95.    used. It builds on the discipline of reference provided by the
  96.    Universal Resource Identifier (URI) as a name (URN, RFCxxxx)  or
  97.    address (URL, RFCxxxx) allows the object of the method to be
  98.    specified.
  99.    
  100.    Reference is made to the Multipurpose Internet Mail Extensions
  101.    (MIME, RFC1341) which are used to allow objects to be transmitted
  102.    in an open variety of representations. 
  103.    
  104. Overall operation
  105.  
  106.    On the internet, the communication takes place over a TCP/IP
  107.    connection. This does not preclude this protocol being implemented
  108.    over any other protocol on the internet or other networks.   In
  109.    these cases, the mapping of the HTTP request and response
  110.    structures onto the transport data units of  the protocol  in
  111.    question is outside the scope of this specification. It should not
  112.    however be at all complicated.
  113.    
  114.  
  115. T. Berners-Lee                                                       2
  116.  
  117. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  118.  
  119.    The protocol is basically stateless, a transaction consisting of 
  120.    
  121.   Connection              The establishment of a connection by the
  122.                          client to the server - when using TCP/IP 
  123.                          port 80 is the well-known port; 
  124.                          
  125.   Request                 The sending, by the client, of a request
  126.                          message to the server; 
  127.                          
  128.   Response                The sending, by the server, of a response to
  129.                          the client; 
  130.                          
  131.   Close                   The closing of the connection by either both
  132.                          parties. 
  133.                          
  134.    The format of the request and response parts is defined in this
  135.    specification. Whilst header information defined in this
  136.    specification is sent in ISO Latin-1 character set in CRLF
  137.    terminated lines, object transmission in binary is possible. 
  138.    
  139. Character sets
  140.  
  141.    In all cases in HTTP where RFC822 characters are allowed, these may
  142.    be extended to use the full ISO Latin 1 character set.  8-bit
  143.    transmission is always used.
  144.    
  145.    tableofcontents 
  146.    
  147.                                REQUEST
  148.                                    
  149.    The request is sent with a first line containing the method to be
  150.    applied to the object requested, the identifier of the object, and
  151.    the protocol version in use, followed by further information
  152.    encoded in the RFC822 header style. The format of the request is: 
  153.    
  154.  
  155.         Request           =     SimpleRequest | FullRequest
  156.  
  157.         SimpleRequest     =     GET URI CrLf
  158.  
  159.         FullRequest       =     Method UR ProtocolVersion CrLf
  160.                                 [*<HTRQ Header>]
  161.                                 [<CrLf> <data>]
  162.  
  163.         <Method>          =     <InitialAlpha>
  164.  
  165.         ProtocolVersion   =     HTTP/V1.0
  166.  
  167.         URI               =     <as defined in URL spec>
  168.  
  169.         <HTRQ Header>     =     <Fieldname> : <Value> <CrLf>
  170.  
  171.         <data>            =      MIME-conforming-message        
  172.  
  173. T. Berners-Lee                                                       3
  174.  
  175. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  176.  
  177.  
  178.  
  179.    The UR is the Uniform Resource Locator (URL) as defined in the
  180.    specification, or may be (when it is defined) a Uniform Resource
  181.    Name (URN)  when a specification for this is settled, for servers
  182.    which support URN resolution.
  183.    
  184.    Unless the server is being used as a gateway, a partial URL should
  185.    be given with the assuptions of the protocol (HTTP:) and server
  186.    (the server) being obvious.
  187.    
  188.    Note. The rest of an HTTP url after the host name and optional port
  189.    number is completely opaque to the client: The client may make no
  190.    deductions about the object from its URL. 
  191.    
  192. Protocol Version
  193.  
  194.    The Protocol/Version field defines the format of the rest of the
  195.    request.. At the moment only HTRQ is defined .
  196.    
  197.    If the protocol version is not specified, the server assumes that
  198.    the browser uses HTTP version 0.9. 
  199.    
  200. Uniform Resource Identifier
  201.  
  202.    This is a string identifying the object.  It contains no blanks. It
  203.    may be a Uniform Resource Locator [ URL ] defining the address of
  204.    an object as described in RFCxxxx, or it may be a representation of
  205.    the name of an object  (URN, Universal Resource Name) where that
  206.    object has been registered in some name space.  At the time of 
  207.    writing, no suitable naming system exists, but this protocol will
  208.    accept such names so long as they are  distinguishable from the
  209.    existing URL name spaces. 
  210.    
  211. Methods
  212.  
  213.    Method field indicates the method to be performed on the object
  214.    identified by the URL.  More details are with the list of  method
  215.    names below . 
  216.    
  217. Request Headers
  218.  
  219.    These are RFC822 format headers with special field names given in
  220.    the list below ,  as well as any other HTTP object headers or  MIME
  221.    headers. 
  222.    
  223. Data
  224.  
  225.    The data (if any) sent with an HTTP request is in a format and
  226.    encoding defined by the object header fields, the default being
  227.    "plain/text" type with "8bit" encoding. Note that while all the
  228.    other information in the request (just as in the reply) is in ISO
  229.  
  230.  
  231. T. Berners-Lee                                                       4
  232.  
  233. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  234.  
  235.    Latin1 with lines delimited by Carriage Return/Line Feed pairs, the
  236.    data may contain 8-bit binary data. 
  237.    
  238.   TERMINATION
  239.   
  240.    The delimiting of the message is determined by the Content-Length:
  241.    field. If this is present, then the message contains the specified
  242.    number of bytes.  If it is not specified, then the message must be
  243.    terminated by a 
  244.    
  245.                         CrLF .  CrLf
  246.  
  247.    sequence.  This sequence may not be followed by any other data.
  248.    (Note: This allows the receiver to check only the end part of each
  249.    received buffer for the start of the termination sequence).  Any
  250.    occurence of the sequence 
  251.    
  252.                         CrLf  .
  253.  
  254.    within the data itself is converted to 
  255.    
  256.                         CrLF  .  .
  257.  
  258.    on transmission and converted back on reception.
  259.    
  260.    This section on termination only applies to data sent with the
  261.    request. It is not required for data in the reply, when connection
  262.    closure by the server is used to indicate the end of the data. 
  263.    
  264.    See also: note on server tolerance for back-compatibility, etc. 
  265.    
  266. Methods
  267.  
  268.    Method field indicates the method to be performed on the object
  269.    identified by the URL.  The methods GET and HEAD below are always
  270.    supported, The list of other methods acceptable by the object are
  271.    returned in response to either of these two requests.
  272.    
  273.    This list may be extended from time to time by a process of
  274.    registration with the design authority.  Method names are case
  275.    sensitive. Currently specified methods are as follows: 
  276.    
  277.   GET                     means retrieve whatever data is identified
  278.                          by the URI, so where the URI refers to a
  279.                          data-producing process, or a script which can
  280.                          be run by such a process, it is this data
  281.                          which will be returned, and not the source
  282.                          text of the script or process. Also used for
  283.                          searches . 
  284.                          
  285.   HEAD                    is the same as GET but returns only HTTP
  286.                          headers and no document body. 
  287.  
  288.  
  289. T. Berners-Lee                                                       5
  290.  
  291. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  292.  
  293.                          
  294.   CHECKOUT                Similar to GET but locks the object against
  295.                          update by other people. The lock may be
  296.                          broken by a higher authority or on timeout:
  297.                          in this case a future CHECKIN will fail. 
  298.                          
  299.   SHOWMETHOD              Returns a description (perhaps a form) for a
  300.                          given method when applied to the given
  301.                          object. The method name is specified in a
  302.                          For-Method: field. (TBS) 
  303.                          
  304.   PUT                     specifies that the data in the body section
  305.                          is to be stored under the supplied URL.  The
  306.                          URL must already exist.  The new contenst of
  307.                          the document are the data part of the
  308.                          request. POST and REPLY should be used for
  309.                          creating new documents.  
  310.                          
  311.   POST                    Creates a new object linked to the specified
  312.                          object. The message-id field of the new
  313.                          object may be set by the client or else will
  314.                          be given by the server. A URL will be
  315.                          allocated by the server and returned to the
  316.                          client. The new document is the data part of
  317.                          the request.  It is considered to be
  318.                          subordinate to the specified object, in the
  319.                          way that a file is subordinate to a directory
  320.                          containing it, or a news article is
  321.                          subordinate to a newsgroup to which it is
  322.                          posted. 
  323.                          
  324.   REPLY                   The same as post, except that the new object
  325.                          is considered to be on an equal footing to
  326.                          the specified object. 
  327.                          
  328.   CHECKIN                 Similar to PUT, but releases the lock set on
  329.                          the object.  Fails if no lock has been set by
  330.                          CHECKOUT. 
  331.                          
  332.   TEXTSEARCH              The object may be queried with a text
  333.                          string.  The search form of the GET method is
  334.                          used to query the object. 
  335.                          
  336.   SPACEJUMP               The object  will accept a query whose terms
  337.                          are the cooridnates of a point within the
  338.                          object. The method is implemented using GET
  339.                          with a derived URL . 
  340.                          
  341.    (Some of these methods require more detailed specification)
  342.    
  343.   GET
  344.   
  345.  
  346.  
  347. T. Berners-Lee                                                       6
  348.  
  349. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  350.  
  351.    A representation of the object is transferred to the client. 
  352.    
  353.     
  354.    
  355.    Some URIs refer to specific variants of an object, and some refer
  356.    to objects with many variants. In the latter case, the
  357.    representations, encodings, and languages acceptable may be
  358.    specified in the header request fields, and may affect the
  359.    particular value which is returned.
  360.    
  361.    Other possible replies allow  a set of URIs to be returned to the
  362.    client, who may use them to retrieve the object.  This allows name
  363.    servers to be implemented using HTTP, and also forwarding address
  364.    to be given when objects have been moved. 
  365.    
  366.   SHOWMETHOD
  367.   
  368.    When an object can support more operations than are defined in this
  369.    specification, SHOWMETHOD allows a client to understand the
  370.    interface to that operation sufficiently to allow the user to
  371.    perform it interactively. 
  372.    
  373.     Required parameter field
  374.     
  375.   For-Method:             This filed contains only the method name
  376.                          about which the client is inquiring. 
  377.                          
  378.     Preconditions
  379.     
  380.    The methodname spacified in the For-Method field must have been
  381.    previously issued in a  "Allowed:" field returned with the given
  382.    object.
  383.    
  384.    The client should specify an Accept: field which includes at least
  385.    one form langauge it it wants to be able to interpret the result. 
  386.    
  387.     Postcondidtion
  388.     
  389.    SHOWMETHOD returns, if possible, a form in a representation
  390.    acceptable to the client.  This form will contain instructions for
  391.    ordering the operation, and fields for the parameters. 
  392.    
  393.   SPACEJUMP
  394.   
  395.    This method is similar to the TEXTSEARCH method, but instead of the
  396.    search criterion being a text string, it is a set of coordinates
  397.    defining a point within the image.  The semantics of the operation
  398.    are not defined here.  Typically, the user clicks on a point within
  399.    the image with a mouse or other pointing device.
  400.    
  401.    Two or more coordinates are supplied, in the order x, y z, t.  All
  402.    coordinates are scaled so that 0 represents the bottom left hand
  403.    point and 1.0 represents the top right hand point. 
  404.  
  405. T. Berners-Lee                                                       7
  406.  
  407. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  408.  
  409.    
  410.    The z access direction follows the normal right-hand rule, that is
  411.    extends toward the viewer when the x and y axes are flat as in the
  412.    normal two-dimensional representation. 
  413.    
  414.    In the case of a time-occupying object, 0 represents the starting
  415.    instance, and 1.0 represents the finishing instant.
  416.    
  417.    The method is implemented using GET with a derived URL . 
  418.    
  419.   TEXTSEARCH
  420.   
  421.    This is a simple form of search. The text is assumed to derive from
  422.    the requesting user, and is in no special format. 
  423.    
  424.    The exact algorithm to be applied is not defined in this
  425.    specification, but techniques such as vocabulary proximity matching
  426.    between the request data portion and the contents or titles of
  427.    documents, keyword matching, stemming, and the use of a thesaurus
  428.    are quite appropriate. 
  429.    
  430.    Whilst this method name is given as a flag to specify that the
  431.    function is available, the search form of the GET method is in fact
  432.    used to query the object. 
  433.    
  434. HTTP Request fields
  435.  
  436.    These header lines are sent by the client in a HTTP protocol
  437.    transaction. All lines are  RFC822 format headers. The list of
  438.    headers is terminated by an empty line. 
  439.    
  440.   FROM:
  441.   
  442.    In Internet mail format, this gives the name of the requesting
  443.    user. This field may be used for logging purposes and an insecure
  444.    form of access protection.  The interpretation of this field is
  445.    that the request is being performed on behalf of the person given,
  446.    who accepts responsability for the method performed.
  447.    
  448.    The Internet mail address in this field does not have to correspond
  449.    to the internet host which issued the request. (For example, when a
  450.    request is passed through a gateway, then the original issuer's
  451.    address should be used).
  452.    
  453.    The mail address should, if possible, be a valid mail address,
  454.    whether or not it is in fact an internet mail address or the
  455.    internet mail representation of an address on some other mail
  456.    system.
  457.    
  458.      
  459.    
  460.   ACCEPT:
  461.  
  462.  
  463. T. Berners-Lee                                                       8
  464.  
  465. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  466.  
  467.   
  468.    This field contains a comma-separated list of representation
  469.    schemes (MIME compatible Content-Type values) which will be
  470.    accepted in the response to this request.
  471.    
  472.    The set given may of course vary from request to request from the
  473.    same user.
  474.    
  475.    This field may be wrapped onto several lines according to RCFC822,
  476.    and also more than one occurence of the field is allowed with the
  477.    signifiance being the same as if all the entries has been in one
  478.    field. The format of each entry in the list is (/ meaning "or") 
  479.    
  480.         <field>  =    Accept: <entry> *[ ; <entry> ]
  481.         <entry>  =    <content type> *[ , <param> ]
  482.         <param>  =    <attr> = <float>
  483.         <attr>   =    q / mxs / mxb
  484.         <float>  =    <ANSI-C floating point text represntation>
  485.  
  486.    See the appendix on the negotiation algorithm as a function and
  487.    penalty model.
  488.    
  489.    If no Accept: field is present, then it is assumed that text/plain
  490.    and text/html are accepted. 
  491.    
  492.     Example
  493.     
  494.                 Accept: text/plain; text/html
  495.                 Accept: text/x-dvi, q=.8, mxb=100000, mxt=5.0; text/x-
  496. c
  497.  
  498.   ACCEPT-ENCODING:
  499.   
  500.    Similar to Accept,  but lists the Content-Encoding types which are
  501.    acceptable in the response.  
  502.    
  503.         <field>  =    Accept-Encoding: <entry> *[ , <entry> ]
  504.         <entry>  =    <content transfer encoding> *[ , <param> ]
  505.  
  506.     Example
  507.     
  508.                 Accept-Encoding: x-compress; x-zip
  509.  
  510.  
  511.   ACCEPT-LANGUAGE:
  512.   
  513.    Similar to Accept, but lists the Language values which are
  514.    preferable in the response.  A response in an unspecifies language
  515.    is not illegal. See also: Language.
  516.    
  517.    Language coding TBS.  (ISO standard xxxx)     
  518.    
  519.  
  520.  
  521. T. Berners-Lee                                                       9
  522.  
  523. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  524.  
  525.   USER-AGENT:
  526.   
  527.    This line if present gives the software program used by the
  528.    original client. This is for statistical purposes and the tracing
  529.    of protocol violations. It should be included.  The first white
  530.    space delimited word must be the software product name, with an
  531.    optional slash and version designator. Other products which form
  532.    part of the user agent may be put as separate words. 
  533.    
  534.         <field>   =   User-Agent: <product>+
  535.         <product> =   <word> [/<version>]
  536.         <version> =   <word>
  537.  
  538.     Example:
  539.     
  540.                UserAgent:  LII-Cello/1.0  libwww/2.5
  541.  
  542.   REFERER:
  543.   
  544.    This optional header field allows the client to specify, for the
  545.    server's benefit, the address ( URI ) of the document  (or element
  546.    within the document) from which the URI in the request was
  547.    obtained. 
  548.    
  549.    This allows a server to generate lists of back-links to documents,
  550.    for interest, logging, etc.  It allows bad links to be traced for
  551.    maintenance.
  552.    
  553.    If a partial URI is given, then it should be parsed relative to the
  554.    URI of the object of the request. 
  555.    
  556.     Example:
  557.     
  558.                Referer: http://info.cern.ch/hypertext/DataSources/Over
  559. view.html
  560.  
  561.   AUTHORIZATION:
  562.   
  563.    This line is present contains authorization information. The format
  564.    is To Be Specified (TBS). The format of this field is in extensible
  565.    form. The first word is a specification of the authorisation system
  566.    in use.
  567.    
  568.    Proposals have been as follows: (and see current one for
  569.    implementation by Ari) 
  570.    
  571.     User/Password scheme
  572.     
  573.                 Authorization:  user  fred:mypassword
  574.  
  575.    The scheme name is "user".   The second word is a user name
  576.    (typically derived from a USER environment variable or prompted
  577.    for), with an optional password separated by a colon (as in the URL
  578.  
  579. T. Berners-Lee                                                       10
  580.  
  581. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  582.  
  583.    syntax for FTP).  Without a password, this povides very low level
  584.    security.  With the password, it provides a low-level security as
  585.    used by unmodified FTP, Telnet, etc. 
  586.    
  587.     Kerberos
  588.     
  589.                 Authorization:  kerberos  kerberosauthenticationsparam
  590. eters
  591.  
  592.    The format of the kerberosauthenticationsparameters is to be
  593.    specified. 
  594.    
  595.   CHARGETO:
  596.   
  597.    This line if present contains account information for the costs of
  598.    the application of the method requested. The format is TBS. The
  599.    format of this field must be in extensible form.  The first word
  600.    starts with a specification of the namespace in which the account
  601.    is . (This is similar to extensible URL definition.) No namespaces
  602.    are currently defined. Namespaces will be registered with the
  603.    registration authority .
  604.    
  605.    The format of the rest of the line is a function of the charging
  606.    system, but it is recommended that this include a maximum cost
  607.    whose payment is authorized by the client for this transaction, and
  608.    a cost unit. 
  609.    
  610. Note: Server tolerance of bad clients
  611.  
  612.    Whilst it is seen appropriate for testing parsers to check full
  613.    conformance to this specification, it is recommended that
  614.    operational parsers be tolerant of deviations.
  615.    
  616.    In particular, lines should be regarded as terminated by the Line
  617.    Feed, and the preceeding Carriage Return character ignored.
  618.    
  619.    Any HTTP Header Field Name which is not recognised should be
  620.    ignored in operational parsers.
  621.    
  622.    It is recommended that servers use URIs free of "variant"
  623.    characters whose representation differs in some of the national
  624.    variant character sets, punctuation characters, and spaces.  This
  625.    will make URIs easier to handle by humans when the need (such as
  626.    debugging, or transmission through non hypertext systems) arises. 
  627.    
  628.                                RESPONSE
  629.                                    
  630.    The response from the server shall start with the following syntax
  631.    (See also:  note on client tolerance ): 
  632.    
  633.   <status line>   ::=    <http version>  <status code>  <reason line> 
  634. <CrLf>
  635.  
  636.  
  637. T. Berners-Lee                                                       11
  638.  
  639. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  640.  
  641.   <http version>  ::=    3*<digit>
  642.   <status code>   ::=    3*<digit>
  643.   <digit>         ::=    0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  644.   <reason line> ::=   * <printable>
  645.  
  646.  
  647.   <http version>         identifies the HyperText Transfer Protocol
  648.                          version being used by the server.  For the
  649.                          version described by this document version it
  650.                          is  "HTTP/1.0" (without the quotes). 
  651.                          
  652.   < status code >         gives the coded results of the attempt to
  653.                          understand and satisfy the request. A three
  654.                          digit ASCII decimal number. 
  655.                          
  656.   <reason string>         gives an explanation for a human reader,
  657.                          except where noted for particular status
  658.                          codes. 
  659.                          
  660.    Fields on the status line are delimited by a single blank (parsers
  661.    should accept any amount of white space). The possible values of
  662.    the status code are listed below . 
  663.    
  664. Response headers
  665.  
  666.    The headers on returned objects are RDC822 format headers with
  667.    special field names given below , as well as any MIME conforming
  668.    headers, notably the Content-Type field. 
  669.    
  670. Response data
  671.  
  672.    Additional information may follow, in the format of a MIME message
  673.    body. The significance of the data depends on the status code. 
  674.    
  675.    The Content-Type used for the data may be any Content-Type which
  676.    the client has expressed his ability to accept, or text/plain, or
  677.    text/html. That is, one can always assume that the client can
  678.    handle text/plain and text/html. 
  679.    
  680. Status codes
  681.  
  682.    The values of the numeric status code to HTTP requests are as
  683.    follows. The data sections of messages Error, Forward and
  684.    redirection responses may be used to contain human-readable
  685.    diagnostic information.  
  686.    
  687.   SUCCESS 2XX
  688.   
  689.    These codes indicate success. The body section if present is the
  690.    object returned by the request. It is a MIME format object. It is
  691.    in MIME format, and may only be in text/plain, text/html or one fo
  692.    the formats specified as acceptable in the request. 
  693.  
  694.  
  695. T. Berners-Lee                                                       12
  696.  
  697. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  698.  
  699.    
  700.     OK 200
  701.     
  702.    The request was fulfilled. 
  703.    
  704.     CREATED 201
  705.     
  706.    Following a POST command, this indicates success, but the textual
  707.    part of the response line indicates the URI by which the newly
  708.    created document should be known. 
  709.    
  710.   ERROR  4XX, 5XX
  711.   
  712.    The 4xx codes are intended for cases in which the client seems to
  713.    have erred, and the 5xx codes for the cases in which the server is
  714.    aware that the server has erred.  It is impossible to distinguish
  715.    these cases in general, so the difference is only informational.
  716.    
  717.    The body section may contain a document describing the error in
  718.    human readable form. The document is in MIME format, and may only
  719.    be in text/plain, text/html or one for the formats specified as
  720.    acceptable in the request. 
  721.    
  722.     Bad request 400
  723.     
  724.    The request had bad syntax or was inherently impossible to be
  725.    satisfied. 
  726.    
  727.     Unauthorized 401
  728.     
  729.    The parameter to this message gives a specification of
  730.    authorization schemes which are acceptable.  The client should
  731.    retry the request with a suitable Authorization header. 
  732.    
  733.     PaymentRequired 402
  734.     
  735.    The parameter to this message gives a specification of charging
  736.    schemes acceptable.  The client may retry the request with a
  737.    suitable ChargeTo header. 
  738.    
  739.     Forbidden 403
  740.     
  741.    The request is for something forbidden. Authorization will not
  742.    help. 
  743.    
  744.     Not found 404
  745.     
  746.    The server has not found anything matching the URL given 
  747.    
  748.     Internal Error 500
  749.     
  750.    The server encountered an unexpected condition which prevented it
  751.  
  752.  
  753. T. Berners-Lee                                                       13
  754.  
  755. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  756.  
  757.    from fulfillingthe request. 
  758.    
  759.     Not implemented 501
  760.     
  761.    The server does not support the facility required. 
  762.    
  763.   REDIRECTION 3XX
  764.   
  765.    The codes in this section indicate action to be taken (normally
  766.    automatically) by the client in order to fulfill the request.  
  767.    
  768.     Moved 301
  769.     
  770.    The data requested has been assigned a new URI, the change is
  771.    permanent. (N.B. this is an optimisation, which must,
  772.    pragmatically, be included in this definition.  Browsers with link
  773.    editing capabiliy should automatically relink to the new reference,
  774.    where possible)
  775.    
  776.    The response contains one or more header lines of the form 
  777.    
  778.        Location: <url> String CrLf
  779.  
  780.    Which specify alternative addresses for the object in question. 
  781.    The String is an optional comment field. 
  782.    
  783.     Found 302
  784.     
  785.    The data requested actually resides under a different URL, however,
  786.    the redirection may be altered on occasion (when making links to
  787.    these kinds of document, the browser should default to using the
  788.    Udi of the redirection document, but have the option of linking to
  789.    the final document) as for "Forward".
  790.    
  791.    The response format is the same as for Moved . 
  792.    
  793.     Method 303
  794.     
  795.         Method: <method> <url>
  796.         body-section
  797.  
  798.    Like the found response, this suggests that the client go try
  799.    another network address.  In this case, a different method may be
  800.    used too, rather than GET. 
  801.    
  802.    The body-section contains the parameters to be used for the method.
  803.     This allows a document to be a pointer to a complex query
  804.    operation. 
  805.    
  806.    The body may be preceded by the following additional fields as
  807.    listed . 
  808.    
  809.  
  810.  
  811. T. Berners-Lee                                                       14
  812.  
  813. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  814.  
  815. Object Headers
  816.  
  817.    The header fields given with or in relation to objects in  HTTP are
  818.    as follows.   All are optional. 
  819.    
  820.    The order of header lines withing the HTTP header has no
  821.    significance. However, those fields which are not MIME fields
  822.    should occur before the MIME fields, so that the MIME fields and
  823.    following form a valid MIME document. This is not mandatory.
  824.    
  825.    Any header fields which are not understood should be ignored.
  826.    
  827.    (TBS in more detail) 
  828.    
  829.   ALLOWED:   *METHOD
  830.   
  831.    Lists the set of requests which the requesting user is allowed to
  832.    issue for this URL.  If this header line is omitted, the default
  833.    allowed methods are "GET  HEAD" 
  834.    
  835.     Example of use:
  836.     
  837.                 Allow: GET HEAD PUT
  838.  
  839.   PUBLIC: *METHOD
  840.   
  841.    As "Allow" but lists those requests which anyone may use.   If
  842.    omitted, the default is "GET" only.  
  843.    
  844.     Example of use:
  845.     
  846.                 Public: GET HEAD TEXTSEARCH
  847.  
  848.   CONTENT-LENGTH: INT
  849.   
  850.    Implies that the body is binary and should be read directly from
  851.    the communications link, without parsing lines, etc.   When the
  852.    data is part of the request, prevents the escaping and de-escaping
  853.    of the termination sequence.
  854.    
  855.    @@@ This should be part of the MIME header, as it applies to any
  856.    binary encoded part. Note HTML is the first internet  protocol to
  857.    allow MIME "binary" encoding. In MIME, the use of Content-Length is
  858.    currently allowed only for external messages. 
  859.    
  860.   CONTENT-TYPE:
  861.   
  862.    As defined in MIME, except: 
  863.    
  864.     Extra non-MIME types
  865.     
  866.    It is reasonable to put strict limits on transfer formats for mail,
  867.    where there is no guarantee that the receiver will understand a
  868.  
  869. T. Berners-Lee                                                       15
  870.  
  871. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  872.  
  873.    weird format. However, in HTTP one knows that the receiver will be
  874.    able to receive it because it will have been sent in the Accept:
  875.    field.  There is therefore a lot to be gained from a very complete
  876.    registry of well-defined types for HTTP which may nevertheless not
  877.    be recommended for mail. In this case, the content-type list for
  878.    HTTP may be a superset of the MIME list.
  879.    
  880.    The x- convention for experimental types is of course still
  881.    available as well. 
  882.    
  883.     Type parameters
  884.     
  885.    Parameters on the content type are extremely useful for describing
  886.    resolutions, colour depths, etc. They will allow a client to
  887.    specify in the Accept: field the resolution of its device.  This
  888.    may allow the server to economise greatly on transmission time by
  889.    reducing the resultion of an image, for example.
  890.    
  891.    These parameters are to be specified when types are registered.. 
  892.    @@ TBS. 
  893.    
  894.   DATE: DATE
  895.   
  896.    Creation date of object.  (or  last modified, and separately have a
  897.    Created: field?)  Format as in RFC850 but GMT MUST BE USED. 
  898.    
  899.   EXPIRES: DATE
  900.   
  901.    Gives the date after which the information given ceases to be valid
  902.    and should be retrieved again. This allows control of caching
  903.    mechanisms, and also allows for the periodic refreshing of displays
  904.    of volatile data.  Format as for Date:. This does NOT imply that
  905.    the original object will cease to exist. 
  906.    
  907.   LAST-MODIFIED: DATE
  908.   
  909.    Last time object was modified, i.e. the date of this version if the
  910.    document is a "living document". Format as for Date:. 
  911.    
  912.   MESSAGE-ID:  URI
  913.   
  914.    A unique identifier for the message. As in RFC850 , except that the
  915.    unlimited lifetime of HTTP objects requires that the Message-ID be
  916.    unique in all time, not just in two years.
  917.    
  918.    A document may only have one Message-ID.
  919.    
  920.    No two documents, even if different versions of the same live
  921.    document, may have the same Message-id.  
  922.    
  923.   VERSION-URI:  1*URI
  924.   
  925.  
  926.  
  927. T. Berners-Lee                                                       16
  928.  
  929. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  930.  
  931.    This gives a URI with which the object may be found.  There is no
  932.    guarantee that the object can be retrieved using the URI specified.
  933.    However, it is guaranteed that if an object is successfully
  934.    retrieved using that uri it will be the same unmodified object as
  935.    this one.
  936.    
  937.    Multiple occurencies of this field give alternative access names or
  938.    addresses for the live document. 
  939.    
  940.   LIVE-URI:  1*URI
  941.   
  942.    This gives a URI with which the most recent version of an object,
  943.    may be found. There is no guarantee that the object can be
  944.    retrieved using the URI specified. However, it is guaranteed that
  945.    if an object is successfully retrieved using that uri that it will
  946.    be the same object or a more recent version of the same object.
  947.    
  948.    Multiple occurencies of this field give alternatives which should
  949.    refer to the same live object. 
  950.    
  951.   LANGUAGE: CODE
  952.   
  953.    The language code is the ISO code for the language in which the
  954.    document is written.  If the language is not known, this field
  955.    should be omitted of course . 
  956.    
  957.    The language code is an ISO 3316 language code with an optional
  958.    ISO639 country code to specify a national variant. 
  959.    
  960.     Example
  961.     
  962.                  Language: en_UK
  963.  
  964.    means that the content of the message is in British English, while 
  965.    
  966.                   Language: en
  967.  
  968.    means that the language is English in one of its forms. (@@ If a
  969.    document is in moe than one language, for example requires both
  970.    Greek Latin and French to be understood, should this be
  971.    representable?)
  972.    
  973.    See also: Accept-Language. 
  974.    
  975.   COST:  TBS
  976.   
  977.    The cost of retrieving the object is given.  This is the cost of
  978.    access of a copyright work.  Format of units to be specified. 
  979.    Currently refers to an unspecified charging scheme to be agreed out
  980.    of band between parties. 
  981.    
  982. Note: Client tolerance of bad servers
  983.  
  984.  
  985. T. Berners-Lee                                                       17
  986.  
  987. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  988.  
  989.    Servers not implementing the specification as written are not HTTP
  990.    compiant.  Servers should always be made completely copmpliant.
  991.    However, clients should also tolerate deviant servers where
  992.    possible. 
  993.    
  994.   BACK COMPATIBILITY
  995.   
  996.    In order that clients using the HTTP protocol should be able to
  997.    communicate with servers using the protocol originally implemented
  998.    in the W3 data model, clients should tolerate responses which do
  999.    not start with a numeric version number and response codes.
  1000.    
  1001.    In this case, they should assume that the rest of the response is a
  1002.    document body in type text/html. 
  1003.    
  1004.   WHITE SPACE
  1005.   
  1006.    Clients should be tolerant in parsing response status lines, in
  1007.    particular they should accept any sequence of white space (SP and
  1008.    TAB) characters between fields.
  1009.    
  1010.    Lines should be regarded as terminated by the Line Feed, and the
  1011.    preceeding Carriage Return character ignored. 
  1012.    
  1013.                       HTTP NEGOTIATION ALGORITM
  1014.                                    
  1015.    This note defines the significance of the q, mxb and mxs values
  1016.    optionally sent in the Accept: field of the HTTP protocol request
  1017.    message.
  1018.    
  1019.    It is assumed that there is a certain value of the presentation of
  1020.    the document, optimally rendered using all the information
  1021.    available in its original source.
  1022.    
  1023.    It is further assumed that one can allocate a number between 0 and
  1024.    1 to represent the loss of value which occurs when a document is
  1025.    rendered into a representation with loss of information.  Whilst
  1026.    this is a very subjective measurement, and in fact largely a
  1027.    function of the document in question, the approximation is made
  1028.    that one can define this "degradation" figure as a function of
  1029.    merely the representation involved.
  1030.    
  1031.    The next assumption is that the other cost to the user of viewing
  1032.    the document is a function of the time taken for presentation.  We
  1033.    first assume that the cost is linear in time, and then assume that
  1034.    the time is linear in the size of the message.
  1035.    
  1036.    The final net value to the user can therefore be written
  1037.    
  1038.    presented_value = initial_value * total-degradation  -   a  - b *
  1039.    size
  1040.    
  1041.    for a document in a given incoming representation.  Suppose we
  1042.  
  1043. T. Berners-Lee                                                       18
  1044.  
  1045. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  1046.  
  1047.    normalize the initial value of the document to be 1.  The server
  1048.    may judge that the value in a particular format is less than 1 is a
  1049.    conversion on the server side has lost information. The total
  1050.    degradation is then the product of any degradation due to
  1051.    conversions internal to the server, and the degradation "q" sent in
  1052.    the Accept field.   If q is not sent, it defaults to 1.
  1053.    
  1054.    The values of a and b have components from processing time on the
  1055.    server, network delays, and processing time on the client.  These
  1056.    delays are not additive as a good system will pipeline the
  1057.    processing, and whilst the result may be linear in message size,
  1058.    calculation of it in advance is not simple.  The amount of
  1059.    pipelining and the loads on machines and network are all difficult
  1060.    to predict, so a very rough assumption must be made.
  1061.    
  1062.    We  make the client responsible for taking into account network
  1063.    delays. The client will in fact be in a better position to do this,
  1064.    as the client will after one transaction be aware of the round-trip
  1065.    time.
  1066.    
  1067.    We assume that the delays imposed by the server and by the client
  1068.    (including network) are additive.  We assume that the client's
  1069.    delay is proportional to message size.
  1070.    
  1071.    The three parameters given by the client to the server are 
  1072.    
  1073.   q                      The degradation (quality) factor between 0
  1074.                          and 1. If omitted, 1 is assumed. 
  1075.                          
  1076.   mxb                    The size of message (in bytes) which even if
  1077.                          immediately available from the server will
  1078.                          cause the value to the reader to become zero 
  1079.                          
  1080.   mxs                    The delay (in seconds) which, even for a very
  1081.                          small message with no length-related penalty,
  1082.                          will cause the value to the reader to become
  1083.                          zero. 
  1084.                          
  1085.    These parameters are chosen in part because they are easy to
  1086.    visualize as the largest tolerable delay and size.  If not sent,
  1087.    they default to infinity.
  1088.    
  1089.    The server may optimize the presented value for the user when
  1090.    deciding what to return.   The hope is that fine decisions will not
  1091.    have to be made, as in most cases the results for different formats
  1092.    will be very different, and there will be a clear winner.
  1093.    
  1094.    A suitable algorithm is that the assumed value v of a document  of
  1095.    initial value u delivered to the network after a delay t  whose
  1096.    transfer length on the net is b bytes is
  1097.    
  1098.    v  =  u * q   -   b/mxb  - t/mxs
  1099.  
  1100.  
  1101. T. Berners-Lee                                                       19
  1102.  
  1103. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  1104.  
  1105.    
  1106.    Note that t is the time from the arrival of the request to the
  1107.    first byte being available on the net.  [[See also: Design issues
  1108.    discussions around this point.]] 
  1109.    
  1110. Note: The cost of retrieval time
  1111.  
  1112.    The assumption that the cost to the user associated with a certain
  1113.    retrieval time is linear in that time is wildly innaccurate.  The
  1114.    real function could be very dependent on circumstances (like go to
  1115.    infinity at a deadline).
  1116.    
  1117.    A better general approximation might be logarithmic for large time
  1118.    delays, and linear for small ones, like a*log(b*t-1) which has two
  1119.    parameters. 
  1120.    
  1121.                         REGISTRATION AUTHORITY
  1122.                                    
  1123.    The HTTP Registration Authority is responsible for maintaining
  1124.    lists of: 
  1125.    
  1126.       Charge account name spaces (see ChargeTo: field above) 
  1127.       
  1128.       Authorization schemes (see Authorization: field above) 
  1129.       
  1130.       Data format names (as MIME Content-Types) 
  1131.       
  1132.       Data encoding names (as MIME Content-Encoding)) 
  1133.       
  1134.    It is proposed that the Internet Assigned Numbers Authority or
  1135.    their successors take this role.
  1136.    
  1137.    Unregistered values may be used for experimental purposes if they
  1138.    are start with "X-". 
  1139.    
  1140.                               REFERENCES
  1141.                                    
  1142.   RFC 822                 "Standard for ARPA Internet Text Messages".
  1143.                          David H. Crocker, describes Internet mail
  1144.                          message fromat. 
  1145.                          
  1146.   RFC850                  "Standard for Interchange of USENET
  1147.                          Messages" This RFC uses some field names in
  1148.                          common with this specification, and is
  1149.                          relevant reading. 
  1150.                          
  1151.   RFC977                 "Network News Transfer Protocol", Kantor and
  1152.                          Lampsley. 
  1153.                          
  1154.   RFC 1341                Multipurpose Internet Mail Extensions
  1155.                          (MIME), Nathaniel Borenstien and Ned Freed,
  1156.                          Internet RFC 1341, 1992. 
  1157.  
  1158.  
  1159. T. Berners-Lee                                                       20
  1160.  
  1161. RFC XXXX              Hypertext Transfer Protocol)        14 July 1993
  1162.  
  1163.                          
  1164.   URL                    Universal Resource Locators. RFCxxx.
  1165.                          Currently available by anonymous FTP from
  1166.                          info.cern.ch as /pub/ietf/url3.{ps,txt}. 
  1167.                          
  1168.   MIME and PEM            Internet Draft only 
  1169.                          
  1170.    
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217. T. Berners-Lee                                                       21
  1218.  
  1219.